JavaScript is a very forgiving language. It’s easy to write code that runs but has mistakes in it.
In this article, we’ll look at the best practices for adding module imports to our JavaScript code and best practices for using iterators and generators.
Multiline Imports Should Be Indented Just Like Multiline Array and Object Literals
Multiline imports should be indented like multiline arrays and object literals.
This means that if we import multiple members from a module and each member is in their own line, then they should have 2 spaces for indentation.
For instance, we write the following to import multiple members in one import statement:
module.js
export const foo = 1;
export const bar = 2;
export const baz = 3;
export const qux = 4;
export const longMember = 5;
export const longMember2 = 5;
export const longMember3 = 5;
export const longMember4 = 5;
export const longMember5 = 5;
index.js
import {
foo,
bar,
qux,
baz,
longMember,
longMember2,
longMember3
} from "./module";
In the code above, we have many members that are exported from module.js and imported in index.jhs .
Since we have lots of members to import and many of them with long names, we should separate them all into their own line with 2 spaces to indent each import to keep everything neat and not overflowing many people’s screens.
No Webpack Loader Syntax in Module Import Statements
Module import statements for style files should follow the module syntax so that it won’t be coupled to the module bundler of our choice.
This makes sense since module bundlers may change in our project depending on our needs.
Therefore, instead of writing the following code:
import stylesCSS from "style!css!styles.css";
We should instead write:
import stylesCSS from "./styles.css";
The 2nd example is standard syntax for import style files, so we should use that instead.
Do Not Include JavaScript Filename Extensions
We don’t need to include the extension for importing modules, so we shouldn’t include it in our import code.
For instance, instead of writing the following:
module.js
export const foo = 1;
index.js
import { foo } from "./module.js";
console.log(foo);
We should write:
import { foo } from "./module";
console.log(foo);
The JavaScript interpreter is smart enough to identify modules by their name rather than their extensions.
Don’t Use Iterators. Prefer JavaScript’s Higher-Order Functions Instead of Loops Like for-in or for-of
JavaScript arrays have many methods that we can use to manipulate arrays, sorting, searching, mapping values, etc. without having to write a single loop.
Therefore we should take advantage of them instead of writing out loops explicitly.
For instance, if we want to map each entry of an array from one value to another, instead of writing a loop as follows:
const arr = [1, 2, 3];
const result = [];
for (const a of arr) {
result.push(a ** 2);
}
In the code above, we have an array arr with some numbers in it. Then we have a for...of loop to loop through the values of an array. In the loop body, we called push on the result , which is initially empty, to push the items into the result array.
This is a lot longer than using the map method with a callback to map array entries into items in a new array with new values.
Then we get that the value of result is [1, 4, 9] .
For example, we can use map to do the same thing as follows:
const arr = [1, 2, 3];
const result = arr.map(a => a ** 2);
In the code above, we called the map method with a callback that maps each array entry taking their value and then return the square of each value.
In the end, we get the same value for result , which is [1, 4, 9] . However, it’s much shorter than what we had before with the for...of loop.
Therefore, we should use higher-order array methods like map , reduce , every , some , sort , filter , find , findIndex , etc. as much as possible.
We can chain them if they return an array.
Conclusion
We should use higher-order array methods instead of using loops to do most array processing. They’re much more concise and we can chain them if they return an array.
Imports don’t need an extension for the module part of the statement. If we import lots of members, then we should separate the members in their own lines with 2 spaces for indentation before each member.
